Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/text/mac/faqs.416

Text File | 1996-02-12 | 28KB | 551 lines

Frequently Asked Questions (FAQS);faqs.416



A. How to Pick your Processor

The following information appeared in article <[e-mail]>
by [e-mail] (|S| Norbert Juffa).  It gives a good indication
of the relative speeds in Intel's processor line:

      UNIX performance of Intel processors as given in Intel's literature


   Processor       SPECmark SPECint SPECfp Whetstone Dhrystone Linpack   Ref Rm
                                           double p.     2.1   dp MFLOPS

1) Intel 386/387-33   4.3    6.4     3.3     3290     15888      N/A      1  *+
2) Intel 386/387-33   4.1    6.0     N/A     3200     18900      0.4      2  #
3) RapidCAD-33        6.6    7.3     6.1     5300     18275      N/A      1  *+
4) 486DX-25           8.7   13.3     6.6     5640     32000      1.0      2
5) 486DX-33          11.1   17.5     8.2     7200     43000      1.5      3
6) 486DX-33          12.1   18.3     9.2      N/A       N/A      N/A      4
7) 486DX-33          14.5   19.0    12.2    12300     43500      1.6      5  &
8) 486DX-50          18.2   27.9    13.6    10710     64400      2.5      3
9) 486DX2-50         19.2   25.4    15.9    18500     63966      2.3      5  &
10)486DX-50          21.9   28.5    18.3    18500     65400      2.4      5  &
11)486DX2-66         25.6   34.0    21.2    24700     85470      3.1      5  &

Remarks:

* Whetstone/Dhrystone are 32-bit DOS results
+ SPEC ratios recomputed from SPEC timings (computed wrong in report)
& note huge increase in SPEC floating point performance over previous results
  due to new experimental FORTRAN compiler
# machine with AMD 386-40/Cyrix 83D87-40/128 kB cache is estimated by me at:
  7.7 SPECint, 5.0 SPECfp, 6.1 SPECmark,
  5600 double prec. Whetstones, 23000 Dhrystones,
  0.6 Linpack double prec. MFlops
  These estimates based on my own measurements and data from:
  FasMath 83D87 Benchmark Report, Cyrix 1990
  World's Fastest 386 40 MHz Am386(tm)DX Microprocessor Performance Summary,
  AMD 1991

References:

1) Intel RapidCAD(tm) Engineering CoProcessor Performance Brief. 1992
2) i486(tm) Microprocessor Performance Report. 1990.
   Order No. 240734-001
3) 50MHz Intel486(tm) DX Microprocessor Performance Brief. 1991.
   Order No. 241120-001
4) i486(tm) Microprocessor Business Performance Brief. 1990.
   Order No. 281352-002
5) Intel486(tm) DX2 Microprocessor Performance Brief. 1992
   Order No. 241254-001

Configurations:

1) COMPAQ SystemPro 386/33 MHz, 8 MB memory, AT&T UNIX System V/386 Release 4.0
   Version 2.0
2) 64 kB write back cache,
   AT&T UNIX System V Release 3.2CC, MetaWare High C R2.2c,
   SVS FORTRAN V2.8
3) COMPAQ SystemPro 386/33 MHz, 8 MB memory, AT&T UNIX System V/386 Release 4.0
   Version 2.0
4) 128 kB write-back cache, 12 MB RAM,
   AT&T UNIX System V Release 3.2CC, MetaWare High C R2.2c,
   SVS FORTRAN V2.8
5) No 2nd level cache, 16 MB RAM,
   AT&T UNIX System V/386 R3.2, MetaWare High C R2.3p
   SVS FORTRAN V2.8
6) ALR PowerCache 33/4e, 128 kB cache, 16 MB RAM
   SCO UNIX System V R3.2.2, MetaWare High C R2.2c/R2.3k,
   SVS FORTRAN V 2.8
7) Intel Modular Platform, 256 kB write-back cache, 32 MB RAM,
   AT&T UNIX System V R4.0.4, Metaware High C R2.4b,
   Intel Scheduling FORTRAN 77 Compiler V0.2
8) 256 kB write-back cache (82495DX/82490DX), 16 MB RAM,
   AT&T UNIX System V/386 R3.2, MetaWare High C R2.3p
   SVS FORTRAN V2.8
9) Intel Modular Platform, 256 kB write-back cache, 32 MB RAM,
   AT&T UNIX System V R4.0.4, Metaware High C R2.4b,
   Intel Scheduling FORTRAN 77 Compiler V0.2
10)Intel Modular Platform, 256 kB write-back cache, 32 MB RAM,
   AT&T UNIX System V R4.0.4, Metaware High C R2.4b,
   Intel Scheduling FORTRAN 77 Compiler V0.2
11)Intel Modular Platform, 256 kB write-back cache, 32 MB RAM,
   AT&T UNIX System V R4.0.4, Metaware High C R2.4b,
   Intel Scheduling FORTRAN 77 Compiler V0.2

One of Intel's most recent wrinkles is the "clock-doubler" chips.  The 50DX2
runs at 25MHz externally but computes at 50MHz.  A 66DX2 (bus speed 33MHz) is
also shipping, and there are persistent rumors of a clock-doubled 50 in the
works that would compute at a blistering 100MHz!  Intel likes to claim a 70%
speedup for the doublers over their undoubled brethren.  I've expressed
skepticism about this in previous issues, but the SPECmarks above suggest that
just this once the marketroids may not be lying -- much.  Under UNIX, a 50DX2
is in fact nearly as fast as a true 50DX.  Still, beware of anyone whose
literature passes off the DX2 qualification in the fine print; they may be
scamming about other things, too.

Right now you'll pay as much as a $500 premium for a 486/50, as that's
relatively new technology and demands extra-fast memory to run full-out.  Also,
these processors run really hot (one correspondent described the 50 as a
"toaster on a chip").  If you go this route, be sure your configuration has an
extra-heavy-duty cooling fan.  Or two.  And, for preference, a hefty heat sink.
Of course, if you do this you'll be ready to drop in the rumored 100DX2 part,
and blow the doors off all those fancy proprietary-technology workstations.

B. Of Memory In...

Buy lots of RAM, it's the cheapest way to improve real performance on any
virtual-memory system.  At $30-$50 maximum per megabyte it's just plain silly
to stick with the 2-4mb now standard on most clone configurations.  Go to 8,
you won't regret it; 16 if you're going to use X.

Above 16 is iffy on ISA boxes because the stock USL 4.0.3 kernel may try to do
DMA from a location the bus can't deal with.  Most UNIX vendors have fixed this
by adding code that forces DMAs to take place from low memory; make absolutely
sure that includes yours before you load up beyond 16MB.  The pc-unix/software
FAQ posting includes information on which vendors are known to have fixed this
problem.

Some motherboards have 16 sockets for SIMM memory modules.  Some only 8.  Some
take only 1MB mdules, some handle 4MB.  These constraints interact in funny
ways.

You should make sure if you are buying an entry level 2 or 6 MB system with a
16-socket motherboard that you will not have to ditch the SIMMs that are
already installed in order to go to your maximum (if 16 MB is your maximum).
Some systems only allow you to mix 1M and 4M SIMMs in certain combinations.
Try not to get any 1M SIMMs in your initial configuration, because you'll
probably end up turfing them later.  That is, buy a 4MB, 8MB, 12 MB or 16MB
system to start.

Newer ISA designs have a 32 MB upper limit with only 8 sockets, since they can
take 4Mx9s...however, this means different interleaving (only 2 banks), which
limits the possible configurations.  You don't want to start off with an 8 MB
configuration, because that's 8 ea 1Mx9's, filling up all the sockets...the
next upgrade requires replacing 1Mx9 with 4Mx9.  You can't even set up 12
MB!...the first reasonable config (that won't require tossing hardware) is 16
MB, since that's one bank full of 4Mx9.

Most EISA motherboards have 16 4MB-capable sockets, and this is clearly
where the market is going.

C. Bus wars

Should you buy 16-bit ISA vs. 32-bit EISA?  You'll pay up to a $300 premium
for the latter.  What you get in return is the ability to use things like fast
32-bit SCSI controllers and a smoother upward-migration path.  On the other
hand, EISA cards are significantly more expensive.  And so far, there isn't
much support for EISA-specific hardware --- a couple of vendors will drive
EISA SCSI disk and tape controllers and that's about it (of course those *are*
the most important bandwidth-eaters).  All ISA cards will still work.

Of course, most of what you get from EISA is a performance boost.  There are
two different theories about why EISA is better; both have their adherents.

Theory A: Bandwidth matters

UNIX has always been an I/O-intensive operating system.  According to this
theory, increasing processor speed on clones can leave it spending all its time
waiting on the limited I/O capacity of the poor old 5.3MB/sec ISA bus.  The
vendors all seem to think this starts at around 33MHz and that if you're buying
50MHz it definitely pays to go EISA.

Theory B: Cache is what matters

According to this theory, UNIX never comes even close to saturating the ISA-bus
bandwidth.  EISA boards are faster because the premium vendors can charge for
them allows the motherboard designer more freedom and a richer parts budget.
The most important performance effect of this is that EISA boards have larger
and better-designed caches, increasing the effective memory-access speed.

There's probably some truth to both analyses.  If your machine is going to
spend most of its processor time running X displays and doing other classically
compute-bound tasks, cache size matters most.  On the other hand, benchmarks
show that the combination of TCP/IP and multi-user disk activity *can* saturate
ISA, and one can sometimes *see* a fast-processor machine slow down during disk
accesses...

If you're contemplating any kind of heavy-duty networking, EISA network
adapters will become rather important.  A correspondent tells me he's seen
benchmarks showing what percentage of bus bandwidth is consumed by various
cards when flooding an ethernet (i.e. consuming the entire 10Mbit bandwidth of
a quiet net, as you might be when doing an FTP transfer, for instance).  8-bit
ISA cards consume 40-60% of bus bandwidth; 16-bit cards, 20-40%.  32-bit EISA
cards consume only about 5-10%.  This would be particularly important in a
machine being used as a bridge, where you might be handling a large portion of
the traffic on two or more separate nets.  The advantage of EISA cards may be
due to their shorter-cycle bus mastering DMA.  At time of writing, only
SCO supports these, but other UNIX vendors are known to have their own drivers
in the pipeline.

D. IDE vs. SCSI (vs. ESDI!)

Another basic decision is IDE vs. SCSI.  Either kind of disk costs about the
same, but the premium for a SCSI card varies all over the lot, partly because
of price differences between ISA and EISA SCSI cards and especially because
many motherboard vendors bundle an IDE chip right on the system board.  SCSI
gives you better speed and throughput and loads the processor less, a win for
larger disks and an especially significant consideration in a multi-user
environment; also it's more expandable.

Another important win for SCSI is that it handles multiple devices much more
efficiently.  If you have two IDE (or ST506 or ESDI) drives, only one can
transfer between memory and disk at once.  In fact, you have to program them at
such a low level, one drive might actually be blocked from *seeking* while
you're talking to the other drive.  SCSI drives are mostly autonomous and can
do everything at once; and current SCSI drives are not quite fast enough to
flood more than 1/2 the SCSI bus bandwidth, so you can have at least two drives
on a single bus pumping full speed without using it up.  In reality, you don't
keep drives running full speed all the time, so you should be able to have 3-4
drives on a bus before you really start feeling bandwidth crunch.

All this having been said, don't write off IDE too quickly.  Sure, it's
compatible with the nasty old ST506 interface, but it's *much* faster.  It
remains the cost-effective choice for smaller drives (up to 500MB) on systems
that won't be hitting the disk constantly.  Unless you're running a heavily
used network or database server, don't assume SCSI will make any noticeable
difference.

One savvy netter observes "Don't discount ESDI, which is making a comeback.
At least with ESDI the system knows what the tracks and sectors are -- the OS
should know this to do good seek optimization."  He goes on to observe that
some ESDI drives are actually faster than SCSI.  ESDI hardware is cheaper, too.
Our editorial opinion is that this is probably a good idea if you're sure
you're *never* going to want a tape drive --- the SCSI/ESDI price difference
will get eathen if you have to buy a separate tape controller.

(If you can do your own installation, I hear that used 150/250MB SCSI drives
are getting quite common and cheap on the net.  All 150MB QIC type drives can
do 250MB on extended-length tapes, though some manufacturers discourage you
from doing this to avoid excessive heade wear.  But back to disks...)

The following, by Ashok Singhal <[e-mail]> of Sun
Microsystems, is a valiant attempt to demystify SCSI terminology.

The terms "SCSI" and "SCSI-2" refer to two different specifications.
Each specification has a number of options. Many of these options are
*independent* of each other.  I like to think of the main options (there are
others that I'll skip over because I don't know enough about them to talk
about them on the net) by classifying them into five categories:

1. Logical
    This refers to the commands that the controllers understand.
    SCSI-2 defined a common cammand set that is pretty much a
    superset of the SCSI command set.

2. Data Width
    8 bits (+ 1 parity) -> "normal"
    16-bits (+ 2 parity) -> "wide"
    32-bits (+ 4 parity) -> I don't know, "extra-wide??"

    All three options are available in SCSI-2 (yes,
    the draft spec I have even shows 32-bits!), although
    8-bit wide is still by far the most common.  Not sure, but I believe
    SCSI defined only 8-bit wide data path.

3. Electrical Interface
    single-ended (max cable length 6 meters)
    differential (max cable length 25 meters)

    Both options are available for SCSI-2 (I'm not sure about SCSI,
    but I think both options were available also)
    and this option is independent of options 2, 4, 5.  Differential
    is less common but allows better noise immunity and longer
    cables.

4. Handshake
    Asynchronous (requests and acks alternate)
    Synchronous (multiple requests can be outstanding)

    Both options are available for SCSI-2 (Not sure about SCSI,
    but I think both were available also).  This is negotiated
    between each target and initiator; asynchronous and synchronous
    transfers can occur on the same bus.  This is independent of
    2, 3 (Not sure about 1).

5. Synchronous Speed (does not apply for asynchronous option)
    "Normal" is up to 5 Mtransfers/sec ( = 5MB/s for 8-bit wide, more
                        for wider)
    "Fast" is up to 10 Mtransfers/s ( = 10 MB/s for 8-bit wide, more
                        for wider)

    The fast option is defined only in SCSI-2.
    This options basically defines shorter timing parameters
    such as the assertion period and hold time.
    The parameters of the synchronous transfer are negotiated
    between each target and initiator so different speed transfers
    can occur over the same bus.

E. Other Disk Decisions

Look at seek times and transfer rates for your disk; under UNIX disk speed and
throughput are so important that a 1-millisecond difference in average seek
time can be noticeable.

Previous issues said "Disk caching is good, but there can be too much of a
good thing.  Excessively large caches will slow the system because the overhead
for cache fills swamps the real accesses (this is especially a trap for
databases and other applications that do non-sequential I/O).  More than 100K
of cache is probably a bad idea for a general-purpose UNIX box; watch out for
manufacturers who inflate cache size because memory is cheap and they think
customers will be impressed by big numbers."  This may no longer be true on
current hardware; in particular, most controllers will interrupt a cache-fill
to fulfill a `real' read request.

In any case, having a large cached hard drive (particularly in the IDEs) often
does not translate to better performance.  For example, Quantum makes a 210Mb
IDE drive which comes with 256Kb cache.  Conner and Maxtor also have 210Mb
drives, but only with 64Kb caches.  The transfer rate on the drives, however,
show that the Quantum comes in at 890Kb/sec, while the Maxtor and Conner fly
away at 1200Kb/sec.  Clearly, the Conner and Maxtor make much better use of
their smaller cache.

Many retailers seem to enjoy advertising the "9ms" Quantum 52/80/120/200Mb
drives.  This speed, of course, is bogus.  All the quantum drives are at least
16ms is average access.  The 9ms already includes the cacheing speedup.

However, it may be that *any* hardware disk caching is a lose for UNIX!  Scott
Bennett <[e-mail]> reports a discussion on comp.unix.wizards:
"nobody found the hardware disk caches to be as effective in terms of
performance as the file system buffer cache...In many cases, disabling the
hardware cache improved system performance substantially.  The interpretation
of these results was that the caching algorithm in the kernel was superior to,
or at least better tuned to UNIX accesses than, the hardware caching
algorithms."

Thus, if your disk controller allows it, try disabling the cache.  Your
throughput may go up!

F. Souping Up X Performance

One good way to boost your X performance is to invest in a graphics card with a
dedicated blitter or high-speed local-bus connection, like the ATI series or
the S3-based Quantum, Wind/X and Orchid Fahrenheit 1280.  A number of clone
vendors offer these accelerator options relatively cheap and can make your X go
like a banshee; however, stock X doesn't support them yet.

SCO's X server supports the ATI Ultra and Fahrenheit 1280, and third-party
servers for SVr4 are available from MetroLink (email [e-mail]) or
SGCS ([e-mail]).

Here is a current price list from MetroLink:

   Runtime (all servers, standard and contrib clients) : 299.00
   Development (full X11 and Motif 1.1.4 libraries)    : 299.00
   Xv - Real-Time Video in an X window (true server    :  99.00
        extension)
   Xie - X Imaging Extension                           : 199.00

And here is the corresponding info from SGCS:

     Ref #                Description                           Price
      -----    ---------------------------------------------     ------
       ** 1    Full X11R5 binaries licensed for a single CPU     295.00
       ** 3    Enhanced X11R5 source code (note 4)               195.00
          4    MIT source code of contributed clients (note 5)    50.00
       ** 5    Motif binaries for a single CPU                   245.00
       ** 7    X11R5 Documentation Set                           150.00
          8    PHIGS Documentation Set                            75.00

    ** DISCOUNTS:
    If your choose more than one selection from any of the (**) items above
    you will receive the following discounts:  $50 off on 2 selections,
    $75 off on 3 selections, $100 off on 4 selections

In general, the ATI approach (normal bus, dedicated blitter and optimization
for special functions like character drawing) will speed up text display, text
scrolling and window resize/move operations a lot, but line-drawing and
graphics only a little.  S3, on the other hand, speeds up high-bandwidth
graphics drawing a lot but doesn't have as big an advantage for ordinary
text operations.  You pays your money and takes your choice.  Benchmarks
indicate that most non-CAD users are better served by the ATI approach.

However, I am now using SGCS X on an S3 with a 17" monitor on a 486/33DX2 and
can report that it is quite fast enough to make X pleasant to use, thank you.
Opaque windows can be dragged like paper.  This is *fun*!

If you're feeling *really* flush, plump for a 15", 17" or even 20" monitor.
The larger size can make a major difference in viewing comfort.  Also you'll be
set for VESA 1280x1024 when everybody gets to supporting that.  In the mean
time, the bigger screen will allow you to use fonts in smaller pixel sizes so
that your text windows can be larger, giving you a substantial part of the
benefit you'd get from higher pixel resolutions.

If you can, buy your monitor from someplace that will let you see the same
monitor (exact same, not the same monitor) that will be on your system.
There's a *lot* of quality variation even in "premium" monitor brands.

The VESA (Video Electronics Standards Association) standard for local bus video
connectors is now out.  When you buy local-bus motherboards, insist that they
be VESA-conforming.  Be very clear about this and get a commitment from your
vendor; some unscrupulous operations may still be attempting to unload pre-VESA
motherboards on unsuspecting customers.

V. Tape Drive Follies

You should have a tape drive for backup, and because most UNIX vendors like to
distribute their OS on tape.  Ideally, your tape backup should be able to image
your entire disk.  Unfortunately, this can get quite expensive for large disks,
as we'll see below.

There are two major technologies in today's desktop tape drive market; QIC
(Quarter Inch Cartridge) at the low end and midrange, and DAT (Digital Audio
Tape) at the high end.  The dividing line is about 1GB capacity.

DAT is a new technology; it's not far down its price curve yet, but clearly
where the future is.  DAT drive capacities are quoted in *gigabytes* (that is,
thousands of megabytes).

Most conventional QIC drives have capacities up to 525 megabytes (a little more
than half a gig).  A few high-end units have 1.35GB capacity.  QIC is a mature
technology, but one plagued by hardware incompatibilities and driver bugs.
Part of the problem is that, until recently, hard disks were small enough
relative to a floppy's capacity that demand for high-volume backup technology
was low in the PC world; QIC vendors tended to be small, insular,
technology-driven firms relatively uninterested in standardization.

As a result, understanding tape drive specifications is far from trivial.
Tape drive standards are develeped by Quarter Inch Cartridge Drive Standards,
Inc. (805-963-3853), a consortium of drive and media vendors.  They develop
standards for controllers, transports, heads, and media.  Some of these
become ANSI standards.  We'll discuss the most iomportant ones here.

Common Tape Drive Interfaces:

    QIC-02     --- intelligent hardware tape interface
    QIC-36     --- simple hardware tape interface
    QIC-104/11 --- SCSI-1 tape interface
    QIC-121    --- SCSI-2 tape interface

These standards describe the drive controller.  QIC-02 is presently by far the
most common, and QIC-36 nearly obsolete (it was designed at a time when
on-board intelligence for controllers was much more expensive than now).  The
SCSI standards are only rarely cited by number; usually, QIC-104 and QIC-121
devices are referred to simply as "SCSI tapes".

Common Recording formats:

    QIC-24     --- 9-track  60-Mbyte tape format
    QIC-120    --- 15-track 125-Mbyte tape format
    QIC-150    --- 18-track 150-Mbyte tape format
    QIC-525    --- 26-track 525-Mbyte tape format

These standards describe the drive itself.

Now, in theory, these standards are upward compatible; that is, a QIC-120 drive
can read a QIC-24 tape, a QIC-150 drive can read both QIC-120s and QIC-24s, and
so on.  There's a potential gotcha here, though, called "media
incompatibility".  Thus, we also need to consider:

Common media:

    DC600A     --- for QIC-24 and QIC-120 drives
    DC6150     --- for QIC-150 drives
    DC6525     --- for QIC-525 drives

The Wangtek 5150ES (and possibly some other 525-megabyte drives) will,
according to its documentation, decode QIC-24 --- but it won't read a DC600A
medium!

So, make sure your tape drive can read the media your OS vendor is going to
ship on.  QIC-24 on DC600As and QIC-150 on DC6150s are very widely used as a
software distribution format in the UNIX world, and you probably want to make
sure your drive can read them.

60/120MB QIC drives are fairly cheap now but larger sizes (typically 150, 250,
525 QIC tapes and 1.3gig DAT) are not.  DAT drives, in particular, cost more
than a grand each (however, if you have large drives the up-front cost
difference can quickly get eaten up by media costs).

One interesting point is that if you've gone SCSI, a 150MB QIC (comparable to
the drives now popular on Suns) may well be cheaper than older 60MB technology;
the win is in the controller prices, which have plummeted since QIC-24 was the
cutting edge.

Tape drives are easy to find and pretty safe to buy through mail order.  It's
also possible to buy reconditioned but warrantied used drives substantially
cheaper than new.  One correspondent recommended Super Technologies of Chino,
CA (800 322 3999); they'll sell you a rebuilt Wangtek 150 with a 7-month
warranty and a controller card for $300 and change, or a DAT drive for $800.

Your humble editor has a few battle scars from tape drive integration at this
point.  We recommend the Archive ST525, a fine fast drive that works nicely
with the Adaptec 1542B, *can* read DC600A/QIC-24, and handles highest-capacity
QIC-525 tapes.  Note however that some versions of its documentation have
a critical typo in the section on setting SCSI drive IDs; they give the ID
jumpers as JP3/JP2/JP1 when they are actually JP8/JP7/JP6.  If you are in
any doubt about your drive or manual, call Archive tech support and check.
Also, it does *not* seem to be able to read QIC-120 tapes as claimed; at least,
125MB backup tapes from my old AT&T 6386WGS are unreadable.

VI. Of Mice and Machines

In a previous issue, I claimed that all mice and trackballs are the same for
compatibility purposes.  I was wrong -- seriously wrong.  The more I found out,
the messier the picture gets.  The following is an attempt to sort out all the
confusion.  Thanks to Jim McCarthy at Logitech for digging into the matter
and somewhat alleviating my ignorance.

Mice and trackballs used to be simple; now, thanks to Microsoft, they're
complicated.  In the beginning, there was only the Mouse Systems 3-button
serial mouse; this reported status to a serial port 30 times a second using a
5-byte serial packet encoding now called "C" protocol.  The Logitech Series 7
and 9 mice were Mouse Systems-compatible.  All UNIXes that have any mouse
support at all understand C-protocol serial mice.

Then Microsoft got into the act.  They designed a two-button serial mouse which
reports only deltas in a three-byte packet; that is, it sends changes in button
status and motion reports only when the mouse is actually moving.  This is
called `M' protocol.  Microsoft sold a lot of mice, so Logitech switched from
`C' to `M' --- but they added a third button, state changes for which show up
in an optional fourth byte.  Thus, `M+' protocol, upward-compatible with
Microsoft's `M'.  Most UNIX vendors add support for M+ mice, but it's wise to
check.

Bus mice are divided into 8255 and InPort types.  These report info
continuously at 30 or 60 Hz (though InPort mice have an option for reporting
deltas only), and you get interrupts on events and then have to poll hardware
ports for details.  More on these next issue.

In addition to serial mice and bus mice, there are "keyboard mice".  On PS/2s
there are two identical-looking keyboard ports, labeled (with icons) "mouse" &
"keyboard".  Both are 8 or 9 pin mini-DIN's that look like the regular PC
keyboard port only smaller.  I don't know what logical protocol the keyboard
mouse speaks.  Physically, the connector is eventually connected to the
keyboard processor (often an 8042).  The same keyboard processor that decodes
the keyboard decodes the mouse.  PS/2s have this port, many newer ISA/EISA
motherboards do as well.

All things considered, UNIX users are probably best off going with a serial
mouse (most current clone motherbords give you two serial ports, so you can
dedicate one to this and still have one for the all-important modem).  Not only
are the compatibility issues less daunting, but a serial mouse loads the
multitasking system less due to interrupt frequency.  Beware that most clone
vendors, being DOS oriented, bundle M-type mice for which UNIX support is
presently spotty, and they may not work with your X.  Ignore the adspeak about
dpi and pick a mouse/trackball that feels good to your hand.

On the other hand: PS/2 mice deliver quadrature output (raw mouse output that
all mice speak) straight to the computer.  This is also how Atari and Amiga
mice work.  This is quite nice, because it makes the mouse simpler (and
therefore more reliable), and because you only get interrupts when the mouse is
actually doing something.  This also means that if your PS/2 mouse breaks you
can get a cheap Atari or Amiga mouse (and they *are* cheaper) to replace it
without sacrificing mechanical quality (which is the important part).

VII. When, Where and How to Buy